Sample Iteration Plan: Elaboration Phase

This illustration shows the relationship of the workflows in an early elaboration iteration. It is constructed from the Workflow Details as they would appear at that time. The intent is to indicate dependencies and show where workflows occur in parallel. The lengths of the bars in the chart (indicating duration) have no absolute significance. For example, it is not intended to convey that Plan for Next Iteration and Manage the Scope of the System must have the same duration. There is also no intention to suggest the application of a uniform level of effort across the duration of the workflows. An indication of the relative effort can be seen in the Process Overview. You can navigate to the corresponding Workflow Detail pages from each line of the chart - just click on the Workflow Detail name. This illustration was created from a Microsoft « Project Plan.

Note that although this is a plan for a single iteration, not all Requirements and Analysis and Design work performed during this iteration is intended for Implementation and Test in this iteration. This explains why the relative effort, within an iteration, for Requirements, Analysis and Design, Implementation and Test, changes through the life-cycle. However, the Iteration Plan will dictate what requirements are explored and refined and what components are designed, even if they are intended for Implementation and Test in a later iteration.

Sample Iteration Plan

Start up: Outline the iteration plan, risks, and architectural objectives.	The Worker: Project Manager starts by sketching a an Artifact: Iteration Plan for the current iteration, based on the outlined Artifact: Software Development Plan during the Initial Iteration in Inception. Evaluation criteria for the architecture are outlined by the Worker: Architect in the Artifact: Software Architecture Document, taking into consideration the "architectural risks" that are to be mitigated (see Artifact: Risk List). Remember that one of the goals of Elaboration is establishing a robust, executable architecture; the plan for doing this needs to be developed in the initial Elaboration iteration.
Environment: Prepare environment for the iteration	The Worker: Process Engineer and the Worker: Tool Specialist prepare the environment for the iteration (see the Workflow Detail: Prepare Environment for an Iteration). An important input is the evaluation of the previous iteration. The Worker: Process Engineer completes the Artifact: Development Case and tailor templates (see Artifact: Project-Specific Templates), to be ready for the iteration, by tailoring (at least) the Analysis & Design workflow and the Implementation workflow. The Worker: Tool Specialist sets up the tools (see Artifact: Tools) to be used in the iteration. If necessary, produce Artifact: Tools Guidelines. The relevant guidelines are developed (see Workflow Detail: Prepare Guidelines for an Iteration).
Requirements: Decide what will "drive" the development of the architecture.	The Worker: Architect and the Worker: Project Manager then determine which use cases and/or scenarios should be addressed in the current iteration; these use cases and/or scenarios drive the development of the architecture (see Workflow Detail: Manage Scope of the System in the Requirements Workflow). The Artifact: Iteration Plan created in previous step should be updated accordingly.
Understand the "drivers" in detail, if necessary; inspect results.	A number of Worker: Use-Case Specifiers then describe in detail the architecturally significant subsets of the selected use cases/scenarios (see Workflow Detail: Refine the System Definition in the Requirements workflow). As the model evolves, the Worker: System Analyst may restructure the Artifact: Use-Case Model to improve the comprehensibility of the model. The changes to the Artifact: Use-Case Model are then reviewed and approved (see Workflow Detail: Manage Changing Requirements in the Requirements Workflow)
The "drivers" of the architecture are reconsidered according to new information; risks also need to be reconsidered.	The use-case view is revisited again by the Worker: Architect, taking into consideration new use-case descriptions, and possibly a new structure of the Artifact: Use-Case Model (revisit Workflow Detail: Manage Scope of the System in the Requirements Workflow). The task now is to select what set of use cases and/or scenarios should be analyzed, designed and implemented in the current iteration. Note again that the development of these use cases and/or scenarios set the software architecture. The Worker: Project Manager again updates the current iteration plan accordingly (see Artifact: Iteration Plan), and might also reconsider risk management, because new risks might have been made visible according to new information (see Artifact: Risk List).
Use-Case Analysis: Find obvious classes, do an initial (high-level) subsystem partitioning, and start looking at the "drivers" in detail.	To get a general feeling of the obvious classes needed, the Worker: Architect then considers the system requirements, the glossary, the use-case view (but not use case descriptions), and the team's general domain knowledge to sketch the outline of the subsystems, possibly in a layered fashion (see Activity: Identify Design Elements in the Analysis & Design Workflow). The analysis mechanisms (common solutions to frequent analysis problems) are also identified by the architect. In parallel with this effort, a team of Worker: Designers, possibly together with the architect, will start finding Artifact: Analysis Classes for this iteration's use cases and/or scenarios, as well as beginning to allocate responsibilities to the identified classes and analysis mechanisms. The designers will use the obvious classes found by the architect as input. Then, a number of designers refine the classes identified in the previous step by allocating responsibilities to the classes, and updating their relationships and attributes. It is determined in detail how the available analysis mechanisms are used by each class. When this is done, the Worker: Architect identifies a number of classes that should be considered as architecturally significant, and includes these classes in the logical view section of the Artifact: Software Architecture Document. The resulting analysis artifacts are then reviewed.
Design: Adjust to the implementation environment, decide how the "drivers" are to be designed, and refine the definition of classes, packages and subsystems; inspect results.	The Worker: Architect then refines the architecture by deriving the design mechanisms (e.g. programming language, database, distribution mechanism, communication mechanism) needed by the earlier identified analysis mechanisms (see Activity: Identify Design Mechanisms in the Analysis & Design Workflow). Artifact: Design Subsystems are defined and design classes are allocated to them; the interfaces to subsystems are identified. Remaining design classes are partitioned into packages, and responsibilities for subsystems and packages are allocated to Worker: Designers. Instances of classes and subsystems are used by designers to describe the realizations of the selected use cases and/or scenarios (see Workflow Detail: Design Components in the Analysis & Design workflow). This puts requirements on the employed model elements and their associated design mechanisms; in the process the interaction diagrams previously created are refined. The requirements put on each design mechanism are handled by the architect (revisit Activity Identify Design Mechanisms in the Analysis & Design workflow). The logical view is updated accordingly by the architect. The resulting design artifacts are then reviewed.
Consider the concurrency and distribution aspect of the architecture.	The next step for the architect is to consider the concurrency and distribution required by the system. This is done by studying the tasks and processes required and the physical network of processors and other devices (see Activity: Describe the Run-time Architecture and Activity: Describe Distribution in the Analysis & Design Workflow). An important input to the architect here are the designed use cases in terms of collaborating objects in interaction diagrams; these objects are allocated to tasks and processes, which in turn are allocated to processors and other devices. This results in both a logical and physical distribution of functionality.
Inspect the architecture	The architecture is reviewed. See Activity: Review the Architecture.
Implementation: Consider the physical packaging of the architecture.	An Worker: Architect now considers the impact of the architectural design onto the implementation model, and defines the initial structure of the implementation model (revisit Activity: Structure the Implementation Model in the Analysis & Design workflow).
Implementation: Plan the integration.	A system integrator now studies the use cases that are to be implemented in this iteration, and defines the order in which subsystems should be implemented, and later integrated into an architectural prototype (see Workflow Detail: Plan the Integration within an Iteration in the Implementation workflow). The results of this planning should be reflected in the Artifact: Software Development Plan.
Test: Plan integration tests and system tests.	A test designer now plans the system tests and the integration tests. Selects measurable testing goals to be used when assessing the architecture. These goals could be expressed in terms of being able to execute a use-case scenario, with a certain response time, or response time under specified load. The test designer also identifies and implements test cases and test procedures. (See Workflow Detail: Plan and Design Test and Workflow Detail: Plan and Design System Test in the Test workflow.)
Implementation: Implement the classes and integrate.	A number of implementers now implement and unit test the classes identified in the architectural design (Step 5, 6, and 7). The implementations of the classes are physically packaged into components and subsystems in the implementation model. The implementers also fix defects (see Workflow Detail: Implement Classes Within an Iteration in the Implementation workflow). The testers integration test the implementation subsystem (see Workflow Detail: Execute Integration Test in the Test workflow), and then the implementers release the tested implementation subsystems to system integration.
Integrate the implemented parts.	The system integrators incrementally integrate the subsystems into an executable architectural prototype (see Workflow Detail: Integrate the System within an Iteration in the Implementation workflow). Each build is tested (see Workflow Detail: Execute Integration Test in the Test workflow).
Test: Assess the executable architecture.	Once the whole system (as defined by the goal of this iteration) has been integrated, the system tester tests the system (see Workflow Detail: Execute System Test in the Test workflow). The test designer then analyzes the results of the test to make sure the testing goals have been reached (see Workflow Detail: Evaluate System Test in the Test workflow). The Worker: Architect will then assess this result and compare it with the risk initially identified.
Assess the iteration itself.	Lastly, the Worker: Project Manager compares the iteration's actual cost, schedule, and content with the iteration plan; determine if rework needs to be done, and if so, assign to future iterations; update the risk list (see Artifact: Risk List); update the project plan (see Artifact: Software Development Plan); and prepare an outline of an iteration plan for the next iteration (see Artifact: Iteration Plan). Productivity figures, size of code, and size of database might be interesting to consider here. The Worker: Project Manager, in cooperation with the Worker: Process Engineer and the Worker: Tool Specialist, evaluate the use process and tools.

Result

The result of this initial iteration would be a first cut at the architecture, consisting of fairly described architectural views (use-case view, logical view, process view, deployment view, implementation view) and an executable architecture prototype.

Subsequent Iterations In Elaboration

Subsequent iterations can be initiated to further enhance the understanding of the architecture. This might imply a further enhancement of the design or implementation model (that is, the realization of more use cases, in priority order, of course). Whether this needs to take place depends on considerations such as the complexity of the system and its architecture, associated risks, and domain experience.

In each iteration the supporting environment is further refined. If the first Elaboration iteration focused on preparing the environment for Analysis & Design, and Implementation, then the second iteration may focus on preparing the test environment. Preparing the test environment includes configuring the test process, and writing that part of the development case, preparing templates and guidelines for test and setting up the test tools.